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REMARKS 

Claims 1-41 remain pending in the application. Reconsideration is respectfully 
requested in light of the following remarks. 

Section 102fe) Rejection : 

The Examiner rejected claims 1, 2, 6-12, 14-18, 22-28, 30 and 34-40 under 35 
U.S.C. § 102(e) as being anticipated by Yalcir et al. (U.S. Publication 2004/0049513) 
(hereinafter "Yakir"). Applicants respectfully traverse this rejection for at least the 
reasons presented below. 

Regarding claim 1, Yakir does not disclose file system software comprising a 
multi-class storage mechanism, wherein the multi-class storage mechanism is configured 
to monitor access of data stored in a multi-class file system comprising a hierarchy of 
storage classes to generate access information for the data, wherein each storage class 
comprises one or more storage devices assigned to the storaee class according to one or 
more characteristics of the storage class . Yakir teaches a multi-disk and multi-volume 
system, but does not disclose a hierarchy of storage classes where each storage class 
comprises storage devices assigned to the storage class according to characteristics of the 
storage class. The Examiner cites paragraphs [0020], [0070], [0090] and [0092] of 
Yakir, asserting that Yakir's "storage units 102 may be organized into one or more 
logical storage units/devices 104" and that a "logical storage unit may reside on non- 
continuous physical partitions." However, Yakir does not mention anything about a 
multi-class file system including a hierarchy of storage classes, where each storage class 
includes storage devices assigned to the storage class according to characteristics of the 
storage class. Instead, Yakir merely discloses multiple storage devices and multiple 
logical storage units. The fact that Yakir's system, includes multiple storage devices/units 
does not disclose the specific limitations of a multi-class file system including a 
hierarchy of storage classes and storage devices assigned to a storage class according to 
characteristics of the storage class. 
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In the Response to Argument, the Examiner argues that Yakir' s servers (SI, S2 
and S3) are equivalent to the storage classes of Applicants' claims. Applicants 
respectfully disagree. Yakir does not teach that the servers of his system represent a 
hierarchy of storage classes in which each storage class includes storage devices assigned 
to the storage class, according to characteristics of the storage class. Additionally, Yakir 
teaches the use of logical storage units, which the Examiner equates to the storage 
devices of Applicants' claims. However, Yakir specifically teaches that a "single logical 
storage unit may span storage space provided by multiple physical storage units" and that 
a "single physical storage unit may be divided into several separately identifiable logical 
storage units" (paragraph [0020]). Yakir also clearly states that a physical storage unit, as 
opposed to a logical storage unit, "is intended to refer to any physical device, system, etc. 
that is capable of storing information or data" (paragraph [0019]), Thus, Yakir' s logical 
storage units are not storage devices, as the Examiner contends. 

The Examiner also refers to Yakir's mention of Hierarchical Storage Management 
(HSM) applications, citing paragraphs [0004] and [0046]. However, Applicants' 
argument is not that Yakir never mentions HSM applications, but that Yakir does not 
disclose a hierarchy of storage classes where each storage class comprises storage 
devices assigned to the storage class according to characteristics of the storage class, as 
argued above. Paragraphs [0004] and [0046] describe stub files, which Yakir describes at 
a physical file tltat represent a migrated file. Neither of the cited paragraphs ([0004] and 
[0046]) supports the Examiner contention that Yakir discloses a hierarchy of storage 
classes where each storage class comprises storage devices assigned to the storage class 
according to characteristics of the storage class. The fact that Yakir's System includes a 
stub file that "stores'information that enables a migrated file to be recalled" does not in 
any way imply the use of a hierarchy of storage classes where each storage class 
comprises storage devices assigned to the storage class according to characteristics of 
the storage class, as recited in Applicants' claim. 
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The Examiner also asserts that each of Yakir's storage units "is generally 
identifiable by a unique identifier that may be specified by the administrator/' However, 
providing a unique identifier for storage unit does not disclose assigning storage units to 
storage classes according to one or more characteristics of the storaee class . The unique 
identifiers to which the Examiner refers merely allow each storage unit to be uniquely 
addressed. Yakir does not mention anything about the unique identifiers being 
characteristics of any storage class. Thus, Yakir fails to disclose wherein each storage 
class comprises one or more storage devices assigned to the storage class according to 
one or more characteristics of the storage class. 

Furthermore, the Examiner argues in the Response to Arguments that Yakir' s use 
of a unique identifier for each logical storage unit "discloses characteristics of the storage 
class", citing paragraph [0020]. The Examiner's is clearly incorrectly interpreting the 
teachings of Yakir. Nowhere does Yakir describe a logical storage unit's identifier as 
representing any sort of characteristic of a storage class. The mere fact that a logical 
storage unit may be assigned a unique identifier by an administrator does not imply any 
sort of characteristic of the logical storage unit. Additionally, the Examiner's has already 
argued that Yakir's servers (SI, S2, and S3) are equivalent to storage classes and also 
argued (erroneously) that Yakir's logical storage units are equivalent to storage devices. 
Thus, the Examiner's is contradicting herself On one hand the Examiner argues that 
Yakir's logical storage units are storage devices (and that the servers are storage classes) 
and on the other hand the Examiner argues that a logical storage unit's unique identifier 
is a characteri stic of a storage class. The Examiner cannot have it both ways. The unique 
identifier for a logical storage unit, which the Examiner considers a storage device, 
cannot also be a characteristic of a storage class, which the Examiner considers to be 
equivalent to Yakir's servers. 

Further regarding claim 1, Yakir also fails to disclose a multi-class storage 
mechanism configured to apply the access information to a set of policies for the multi- 
class file system . The Examiner cites FIG. 1, item 114 and paragraph [0023] of Yakir. 
However, item 114 of FIG. 1 and paragraph [0023 J merely disclose that Yakir system 
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includes "information 1 14 related to storage policies and rules configured for the storage 
environment" (Yakir, paragraph [0023]). Yakir does not, however, teach anything 
regarding applying access information (generated from the monitoring of data stored in a 
multi-class file system) to a set of policies for the multi-class file system. Yakir does not 
teach anything regarding applying any access information to the storage policies and 
rules of information 1 14. Nor does Yakir describe applying access information to any 
other set of policies. The mere existence of storage policies does not inherently include 
or imply applying access inforcnation to storage policies. Without some specific 
disclosure by Yakir regarding applying access information to a set of policies, Yakir 
cannot be said to anticipate a multi-class storage mechanism configured to apply access 
information to a set of policies for a multi-class file system. 

In the response to arguments, the Examiner cites paragraphs [0023] and [0046] 
and argues that in Yakir' s system information used to find or locate migrated data may be 
stored in the same database as "information related to storage policies and rules 
configured for the storage environment". However, the sentence cited by the Examiner is 
the only reference by Yakir to such polices or rules. Thus, the Examiner is arguing that 
since Yakir mentions that information used to locate migrated data may be stored 
together with (in the same database as) "information related to storage policies", Yakir 
somehow discloses the specific limitation of applying access information to a set of 
policies for a multi-class file system, as recited in Applicants 5 claim. The Examiner's 
position clearly goes beyond the actual teachings of Yakir. A single sentence stating that 
location information and "information related to policies" may be stored in the same 
database does not, in any way, disclose applying access information to a set of policies. 
Storing different types of information together does not imply that one set of information 
is applied to the other. 



Additionally, Yakir fails to disclose a multi-class storage mechanism configured 
to migrate a portion of the data to different storage classes in the hierarchy of storage 
Masses in response to the application of acMw s information to the set of policies for the 
multi-class file system. The Examiner cites the same portions of Yakix (FIG. 1, item 1 14 
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and paragraphs [0020], [0023], [0070], [0090] and [0092]). However, none of the cited 
passages mentions anything about migrating data to different storage classes in response 
to the application of access information to the set of policies. The Examiner refers to 
Yakir's teachings regarding migrating a stub file from one storage unit to another, but 
fails to cite any portion of Yakir that discloses migrating a stub file in response to the 
application of access information to a set of policies. Instead, Yakir teaches that a stub 
file is migrated in response to an originating server receiving a signal to move a stub file 
and that "[t]he signal may be received from a user, an application or program, or from 
other like source" (Yakir, paragraph [0063]). Thus, Yakir discloses migrating a stub file 
in response to a signal from a user, application or a similar source. A signal from a user 
or an application cannot be considered an application of access information to a set of 
policies. Yakir clearly does not describe migrating data in response to the application of 
access information to a set of policies. 

In the Response to Arguments, the Examiner cites paragraph [0011] of Yakir 
referring to Yakir's teachings that "information (such as information 11 related to 
policies) can be used to determine the location of the migrated data" (parenthesis by 
Examiner). However, the Examiner's argument fails to support the Examiner's position. 
Firstly, the cited paragraph does not support the Examiner's contention that "information 
related to polices" can be used to determine the location of migrated data. Instead, 
paragraph [0011] states that a stub file stores information that can be used to determine 
the location of migrated data, Secondly, the fact that information (whether related to 
policies or not) may be used to locate migrated data, i.e. data that has already be migrated 
does not disclose migrating data to different storage classes in response to applying 
access information to a set of policies. The Examinees argument that after being 
migrated, information related to policies may be used to located the migrated data says 
nothing about whether the data was migrated in response to anything. 

Applicants remind the Examiner that anticipation requires the presence in a single 
prior art reference disclosure of each and every limitation of the claimed invention, 
arranged as in the claim , M.P.E.P 213 1 ; Lindemann Maschinenfabrik GmbH v. American 
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Hoist & Derrick Co., 221 USPQ 481, 485 (Fed. Cir. 1984). The identical invention must 
be shown in as complete detail as is contained in the claims. Richardson v. Suzuki Motor 
Co., 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). As discussed above, Yakir fails to disclose 
a multi-class storage mechanism configured to monitor access of data stored in a multi- 
class file system comprising a hierarchy of storage classes to generate access information 
for the data, wherein each storage class compris es one or more storage devices assigned 
to . the storage class according to one or more characteristics of the storage class . Yakir 
further fails to disclose that the multi-class storage mechanism is configured to apply the 
access information to a set of policies for the multi-class file system and to migrate a 
portion of the data to different storage classes in the hierarchy of storage classes in 
response to the application of access i nformation to the set of policies for the multi-class 
file system. Therefore, Yakir cannot be said to anticipate claim 1 . 

For at least the reasons above, the rejection of claim 1 is not supported by the 
cited art and removal thereof is respectfully requested. Similar remarks apply to claims 
14, 16 and 30. 



Regarding claim 15, Yakir fails to disclose a system including means for means 
for implementing a multi-class file system including a hierarchy of storage classes on a 
plurality of storage devices, where each storage class includes one or more of the storage 
devices assigned to the storage cl ass according to one or more characteristics of the 
st orage class . Please refer to the remarks above regarding claim 1, for a detailed 
discussion of Yakir's failure to disclose a multi-class file system including a hierarchy of 
storage classes on a plurality of storage devices, where each storage class includes one or 
more of the storage devices assigned to the storage dass according to one or more 
characteristics of the storage class . 



Yakir further fails to disclose software means for assigning a migrating data tg 
different storage classes in the hierarch y of storage classes according to a set of p nli^ 
for the mulri-class file system. The Examiner does not cite any portion of Yakir that 
describes migrating data to different storage classes in a hierarchy of storage classes. 
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Yakir only mentions that data may be migrated from an original storage location on an 
original volume to a repository storage location on a repository volume and that a stub 
flic may also be migrated from an original storage location to another storage location. 
However, Yakir does not mention migrating data to different storage classes in a 
hierarchy of storage classes. In fact, Yakir makes not mention of different storage 
classes at all. The Examiner equates the mere fact that Yakir's system includes multiple 
physical storage devices and multiple logical storage units as including a hierarchy of 
storage classes. However, merely providing multiple physical storage devices and 
multiple logical storage units does not disclose anything regarding different storage 
classes or about a hierarchy of storage classes. 

Nor does having multiple physical/ logical storage units disclose anything about 
migrating data according to a set of policies for a multi-class file system. Yakir merely 
describes the existence of storage policies and rules (Yakir, paragraph [0023]), but fails 
to disclose migrating data to different storage classes according to a set of policies. As 
noted above regarding claim 1, Yakir described migrating a stub file in response to 
receiving a signal from a user, application, program, or other like sources. Nowhere does 
YaMr mention anything regarding migrating data according to a set of policies. 

Thus, the rejection of claim 15 is not supported by the cited art and removal 
thereof is respectfully requested. 

Regarding claim 2, Yakir fails to disclose file system software that includes file 
system functionality configured to implement the hierarchy of storage classes of the 
multi-class file system. The Examiner cites paragraphs [0020], [0070], [0090] and 
[0092] of Yakir and asserting that in Yakir's system, "[pjhysical storage units 102 may 
be organized into one or more logical storage units/devices 104" and that a "logical 
storage unit may reside on noncontiguous] physical partitions." However, as noted 
above regarding the rejection of claim 1, merely having multiple physical and logical 
storage units where a logical storage unit may reside on non-contiguous physical 
partitions does not disclose or imply a hierarchy of storage classes. Thus, Yakir fails to 
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disclose a hierarchy of storage classes. Additionally, Yakir fails to disclose file system 
functionality configured to implement the hierarchy of storage classes. Yakir only 
teaches that data may be migrated from an original storage location to another storage 
location but makes no mention of any file system functionality configured to implement a 
hierarchy of storage classes. Thus, the rejection of claim 2 is not supported by the cited 
art and removal thereof is respectfully requested. Similar remarks also apply to claim 1 8. 

Regarding claim 7, Yakir fails to disclose where the multi-class storage 
mechanism is configured to modify file system metadata for the migrated data to indicate 
the different storage classes for the migrated data. The Examiner cites paragraphs [0049- 
0053] of Yakir. This portion of Yakir describes that data, metadata and stub files may be 
migrated but does not mention anything regarding modifying metadata to indicate 
different storage classes for migrated data. Yakir does not disclose any kind of indication 
of different storage classes for migrated data, either in metadata or elsewhere. Merely 
describing that data, metadata and stub files can be migrated does not disclose the 
specific limitation of modifying file system metadata to indicate different storage classes 
for the migrated data. 

In the Response to Arguments, the Examiner cites paragraphs [0067] and [0078] 
of Yakir, referring to Yakir teaching regarding "the originating server modify/update 
information stored in a database". However, the sentence cited by the Examiner (in both 
paragraph [0067] and paragraph [0078]) actually states, "[t]he originating server may 
modify/update information stored in a database . , . using database update techniques such 
as ODBC techniques." In fact, both cited paragraphs are about techniques used to inform 
storage management server (SMS) 110 regarding a stub file. In one case (paragraph 
[0067]) Yakir teaches that SMS 1 10 is informed that a stub file now resides on a different 
volume and in the other case (paragraph [0078]) Yakir teaches that SMS 1 10 is informed 
that a stub file is no longer eligible for remigration. Nothing in the cited passages has any 
anything to do with modified file system metadata for migrated data to indicate the 
different s torage classes for the migrated data. Informing a server that a stub file is on a 
different volume does not imply that the different volume is on a different storage class 
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and information a server that a stub file is ineligible for remtgration also fails to imply 
anything about indicating different storage classes for the migrated data. 

Thus, the rejection of claim 7 is not supported by the cited art and removal thereof 
is respectfully requested. Similar remarks also apply to claims 23 and 35. 

Regarding claim 11, Yakir fails to disclose file system software that is configured 
to add a new storage class to the hierarchy of storage classes. The Examiner cites 
paragraph [0006] of the background section of Yakir and refers to Yakir' s teaching 
regarding reorganizing data when deploying new servers. However, the cited passage of 
Yakir does not describe anything about adding a new storage class to a hierarchy of 
storage classes. Instead, the cited passage describes how stub files may be moved from 
one storage location to another for various reasons, including reorganizing data when 
deploying new servers and storage devices. No mention is made about adding a new 
storage class to a hierarchy of storage classes. In fact, nowhere does Yakir mention file 
system software configured to add a new storage class to the hierarchy of storage classes. 

In the Response to Arguments the Examiner argues that merely by describing that 
a stub file may be moved "from, its present location to a new destination storage location" 
Yakir discloses file system software that is configured to add a new storage class to the 
hierarchy of storage classes . Applicants respectfully disagree with the Examiner's 
interpretation. Merely moving a stub file, or other data, to a new destination does not in 
any way imply that a new storage class is added to a hierarchy of storage classes. Data 
can be moved between locations within a single volume, devices, and certainly with a 
single storage class. Moreover, even if data is moved from one storage class to another, 
thai does not necessarily involve adding a new storage class to a hierarchy of storage 
classes. The mere fact that Yakir mentions that a stub file may be moved to a new 
destination storage location" clearly does not disclose file system software that is 
configured to add a new storage class to the hierarchy of storage classes . 
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Thus, for at least the reasons above, the rejection of claim 1 1 is not supported by 
the cited art and removal thereof is respectfully requested. Similar remarks also apply to 
claims 27 and 39. 

Section 103(a^ Rejections : 

The Examiner rejected claims 3-5, 13, 19-21, 29, 31-33 and 42 under 35 U.S.C. § 
103(a) as being unpatentable over Yakir in view of Leung et ah (U.S. Publication 
2004/0039891) (hereinafter "Leung"), and claims 5, 21 and 33 as being unpatentable over 
Yakir in view of Gill (U.S. Patent 6,947,959). Applicants respectfully traverse the 
rejections of these claims for at least the reasons presented above regarding their 
respective independent claims. 

Further regarding claim 3, Yakir in view of Leung does not teach or suggest 
storage classes that are ordered in a hierarchy of storage classes according to performance 
characteristics from a highest storage class comprising high-performance storage devices 
to a lowes t storage class comprising low-performance storage devices . The Examiner 
admits that Yakir does not teach storage classes ordered in a hierarchy according to 
performance characteristics but relies upon Leung, citing paragraphs [0037-0038] and 
[0053-0054]. However, none of the cited paragraphs mentions storage classes ordered in 
a hierarchy of storage classes according to performance characteristics. Instead, the 
cited paragraphs describe storage units may be classified into groups according to the 
data storage cost, such as a monetary value of storage data per unit of storage. Yakir also 
describes using other criteria, such as volume capacity, manufacturer, or device type, to 
group storage units. However, Leung fails to mention anything regarding storage classes 
ordered according to performance characteristics. 

Yakir and Leung, whether considered singly or in combination, fail to teach or 
suggest storage classes that are ordered in a hierarchy of storage classes according to 
performance characteristics from a high est storage class comprising high-performance 
storage de vices to a lowest storage class comprising low-performance storage devices . 
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In the Response to Arguments, the Examiner cites paragraphs [0070] and [0091] 
and arguing that "rank" and "order" are equivalent. First of all the Examiner fails to state 
whether the cited paragraphs are from Yakir or Leung. Furthermore, paragraphs [0070] 
and [0091] of both Yakir and Leung fail to mention anything regarding storage classes 
that are ordered (or ranked) in a hierarchy according to performance characteristics from 
ahjghest storage class comprising high-performance storage devices to a lowest storag e 
class comprising low-performance storage devices . 

Paragraph [0070] of Yakir states that a stub file may be moved "without recalling 
migrated data associated with the stub file". Paragraph [0091] of Yakir describes that 
data locator information is stored in a stub file and that moving the stub file from the 
originating storage location to the destination storage location essentially moves the 
information stored by the stub file from the originating storage location to the destination 
storage location. 

Paragraph [0070] of Leung states that when an overcapaci ty condition (e.g., when 
the used storage capacity for a volume exceeds a user-configured threshold value) is 
detected, a target volume is then automatically and dynamically determined for receiving 
files from the source volume to resolve the overcapacity condition and that data is moved 
from a source volume to a target volume that has a lower storage data cost associated 
with it. However, moving data to a volume that has lower storage data cost does not 
disclose storage classes that are ordered in a hierarchy of storage classes according to 
performance characteristics from a highest storage class comprising high-performance 
storage devices to a l owest storage class comprising low-performance storage devices . 
Storage cost and performance are two different things. 

Paragraph [0091] of Leung describes file groups. Leung teaches that a file is 
included in a file group if the file satisfies criteria specified for the file group and that the 
file group criteria may be specified by the administrator or some other user. Leung give 
the example that an administrator may create file groups based upon a business value 
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associated with the files where the administrator may group files that are deemed 
important or critical for the business into one file group (a "more important" file group) 
and die other files may be grouped iuto a second group (a "less important" file group). 
However, grouping files is not the same as storage classes that are ordered in a hierarchy 
of storage classes according to performance characteristics. Additionally, the Examiner 
has previously argued that Yakir's servers SI, S2 and S3, not Leung file groups are 
storage classes. Grouping files as taught by Leung does not teach or suggest ordering 
storage classes (or Yakir's servers) according to performance characteristics. 

Thus, for at least the reasons above, the rejection of claim 3 is not supported by 
the cited art and removal, thereof is respectfully requested. Similar remarks also apply to 
claims 19 and 31. 

Regarding the section § 102 and § 103 rejections, Applicants also assert that 
numerous other ones of the dependent claims recite further distinctions over the cited art. 
However, since the rejections have been shown to be unsupported for the independent 
claims, a further discussion of the dependent claims is not necessary at this time. 
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RECEIVED 
CENTRAL FAX CENTER 



JUL 1 2 2006 



CONCLUSION 



Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any fees ate due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C Deposit Account No. 501505/5760- 
149Q0/RCK. 

Also enclosed herewith are the following items: 
Q Return Receipt Postcard 

□ Petition for Extension of Time 
G Notice of Change of Address 

□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: July 12. 2006 



Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



1 0/750,597 {5760-1 49OQ/VRTS0526) 
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Meyertons. Hood, Kivlin, Kowert & Goetzel, P.C. 
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